OpenEdge Development:<br />Progress Dynamics Basic Development Object IDs

Every Progress Dynamics table has a unique identifier called an object ID. The field has a DECIMAL data type. The field’s name is the table name, without the three-character table-type prefix, and ending with the suffix _obj. For example, the object ID field for the ryc_attribute_group table is attribute_group_obj. The object ID values are assigned using a globally unique site number, as described in the "Site numbers" section.

Because the Object IDs are assigned using globally unique site numbers, every record in every table in every Progress Dynamics-managed database can have a common key value that is guaranteed to be unique worldwide, like a RECID. Using this mechanism, you can easily locate and refer to any record in any table in a database using a standard mechanism. You only need to know the table name (or its abbreviation, its abbreviated name, or dump name) and its Object ID. The framework does this to support a number of standard operations that can apply to any table, including auditing and record-specific data security.

The unique site numbers allow data from different Repository databases to be combined without fear of collisions between object ID values. Application tables can also be safely combined as long as there are no other unique key values that could conflict between databases. You can use this technique to merge dynamic application components from different sources into a single application or suite of applications.

For example, you develop a new feature that includes one or more dynamic (data-driven) components, such as a table maintenance window, and you want to submit it for inclusion in Progress Dynamics. Your Repository database must have a unique site number. Otherwise, your Repository data could not reliably be deployed to the central Repository database. You would encounter the same issue if you wanted to integrate your application with a Progress Dynamics application from another vendor.

For this reason, it is imperative that you obtain a unique site number for your development database and for each distinct, deployed database before undertaking any work that might require sharing Repository or application data between databases, for cooperative development, or as part of the deployment of your application. Also note that the site ID becomes part of the object ID.

Because the object ID is useful for comments, auditing, and similar tasks, you should provide object IDs for all the tables in any database you create. Even if you have an existing database, you might want to consider adding object IDs to the tables where the size of existing deployed databases permits.

The standard naming convention for object IDs provides other benefits. For example, the object ID is always used to define foreign key relationships. If the table name is xyz_table_name, its object ID field is table_name_obj. If there is a foreign key relationship to another table, then the table_name_obj field also appears in that table. It is easy to build tools that recognize and take advantage of this relationship.

Having the object ID field appear on the foreign table yields another benefit. The framework searches for fields from the foreign table, in addition to a foreign key field, that are appropriate to retrieve and display. These are fields that describe the foreign key field. The framework finds these fields by searching for names containing strings from a list of meaningful descriptive field names. The following list shows the default values:

reference

code

last_name

short (for “short description”)

id

desc

name

The Object Generator uses this technique to identify useful fields from related tables to include in the SDO field list.

You are building an SDO for a table.

There is a foreign key relationship of this type to another table.

That table contains a field name that matches one of the strings that describe the foreign key field.

The other table is added to the SDO’s query.

The descriptive name field from the other table is added as a read-only field to the SDO field list.

If you are building a new database using the naming convention, you can take advantage of features such as this without additional effort. For more information, see Chapter 5, " Using the Object Generator."